Graphical User Interface for System and Method for Managing Content

ABSTRACT

A system and method for electronic file management includes an object-oriented file management database, a volume manager, and a coherency manager. The volume manager manages electronic files and metadata relating to the files of one or more volumes. Each volume may include folders, files, and/or other digital content. A user interface facilitates user interaction with the file management system. The user interface enables a user to view and manage, within the file management system, metadata associated with the electronic files by graphically displaying information about the files and the metadata and enabling the user to manipulate the files and the metadata.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S.Non-Provisional application Ser. No. 10/632,087 filed Aug. 1, 2003 whichclaims priority to U.S. Provisional Application Ser. No. 60/434,418entitled “FILE MANAGEMENT SYSTEM AND METHOD” which was filed on Dec. 19,2002, each is incorporated herein by reference in their entireties. Thisapplication is also related to corresponding U.S. patent applicationSer. No. 10/632,092 entitled “System and Method for Managing Content”;U.S. patent application Ser. No. 10/632,091 entitled “System and Methodfor Managing Content Including Content Addressability Features”; U.S.patent application Ser. No. 10/632,105 entitled “System and Method forManaging Versions”; and U.S. patent application Ser. No. 10/632,086entitled “System and Method for Managing Content With Event DrivenActions to Facilitate Workflow and Other Features,” each of which isincorporated herein by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates to an integrated system and method formanaging files, messages and other digital content that facilitatescategorization of information, provides version control, allowsevent-driven actions including control of workflow, permits sharing andaccess control of files, is transactionally-based to permit easyhistorical viewing and undoing of a wide variety of changes to files andfolders and other features, and a graphical user interface to facilitateaccess to and use of such a system.

BACKGROUND OF THE INVENTION

Computers have revolutionized the storage, retrieval and use ofinformation. As the costs and size of computer memory has gone down, theamount of information accessible to a user has increased substantially.The expansion of networks, including global networks, such as theInternet, has also greatly contributed to this growth. This growth hasgreatly outpaced the ability of existing systems to find, share andorganize that information.

Originally, electronic file systems were based upon simple filingconcepts from paper files. Files were organized into folders andsubfolders, just like documents in filing cabinets. As the number andtypes of files have grown, the inadequacies of the early systems havebecome increasingly apparent. In the physical environment, as the numberof filing cabinets increased, indexing systems were developed to locatespecific files or documents. Such systems are still used in controllingphysical documents. In the electronic realm, similar file managementsystems have also developed. However, networks have changed the natureof file storage. A user is no longer limited to the files on a singlecomputer. Instead, a single user can create, store, access, modify andcopy files on any number of machines, including their own computer,network servers, and even co-workers computers. Additionally, others ona network may be creating, copying, and modifying those same files. Theexploding use of email has also contributed to current problems. Emailsare also retained and they need to be organized and controlled, so thatthey can be later located, accessed and used. Within existing computerfiling systems, disorganization is rampant, and it can be hard to findthings. In recent years, various disparate applications have emerged tosolve some aspects of the problems: Version Control systems, DocumentManagement systems, Workflow systems, Configuration Management systems,Archiving systems, Backup systems, general purpose databases, etc. Theseapplications are yet other places to store files, in systems that haveto be learned, maintained, backed up, etc.

One of the many problems with existing electronic filing systems is thecreation of copies. It is very easy to copy a file. There are alsoimportant reasons why a copy of a file may be better than the original,in terms of accessibility and convenience. However, the creation of manycopies further increases the disorganization of filing systems. Studieshave shown that most of the files on people's computers and disks arecopies of files from other computers on the network, from read-onlymedia, and from their own computer.

The creation of copies can be very confusing. The original file may bechanged, or the copy may be changed. Then, they are no longer exactcopies, but a user can easily lose track of which is the correct one.Many times the creator of a copy forgets about it or why it was created.The copy then continues to exist, using valuable storage and name space,but without any purpose. The vast majority of copies are not necessary.Therefore, a need exists for a file management system with improvedperformance such that the need for copies is limited. Furthermore, aneed exists for a file management system that maintains informationabout copies of files so that its use and relationship to other filescan be easily determined.

Another problem with current file systems is that different users mayuse different approaches to file organization. This leads todifficulties in finding and sharing files. Another problem is the waythat access control and sharing are managed. The sharing and accesscontrol features in the Windows™ operating system, for example, are verydifficult for the average user to make sense of, to use and to maintain.An advanced user is typically needed to establish and maintain filesharing groups and related mechanisms. Improper sharing and accesscontrol may allow access to information that should not be disclosed, orfiles may be inaccessible that should be shared. Therefore, a needexists for a file management system that allows simple control of accesscontrol and file sharing.

Locating a desired file is another complicated process in existingsystems. Each computer or disk drive is often searched separately, eventhough information may be stored on several different, interconnected,computers. Even if a search looks for a file on multiple computers, thesearch results can be misleading or incomplete. The problems with copiesmay mean that a search may produce many duplicate results and resultsthat do not include the best version. The system provides little, ifany, assistance in determining which is the proper (e.g. current) file.Therefore, a need exists for a file management system that allowssearching on multiple computers and organizes results in a usefulmanner.

It is well known that it is advisable to maintain backup copies of filesin case of corruption, loss, or other problems. However, there arenumerous problems with backup systems. Often, backup systems are notinstalled or operated on a regular basis. Sometimes, backups do notsucceed when scheduled. Very often, only essential servers are backedup; the files on individual computers typically are not regularly backedup. Additionally, locating and retrieving a backup file can bedifficult. Therefore, a need exists for a file management system thatsimplifies the backup and restoration processes. Other drawbacks exist.

SUMMARY OF THE INVENTION

An object to the invention is to overcome these and other drawbacks. Thepresent invention substantially overcomes the deficiencies of the priorart through a novel file management system. According to one aspect ofthe invention, the file management system includes an object orientedfile management database. The file management system includes a volumemanager and a coherency manager. The volume manager manages a set ofvolumes. Each volume may include folders, files and other digitalcontent, and it may reference other volumes. The coherency manager,among other things, facilitates consistency among multiple volumemanagers. According to another aspect of the invention, a novel userinterface for interacting with the file management system is provided.

Unlike conventional file management systems, the file management systemof the present invention is content addressable and self-organizing tofacilitate categorization of information, includes a publish/subscribecapability and event-driven actions to facilitate sharing and accesscontrol of files and workflow, is transactionally-based to facilitatethe ability to enable a historical view showing actions performed onthat file or folder and restoring files and folder to states prior to achange. As detailed below, these and other aspects of the inventionenable a number of advantageous features.

According to one embodiment, implementation of the contentaddressability feature includes the use of tags. Tags are name-valuepairs that describe folder or file attributes. Tags can have a singlevalue or, in some cases, multiple values. According to one aspect of theinvention, some tags may be system generated tags and others may be userselected tags. Via the user interface, for example, by right clicking ona file or folder and selecting tags from a menu, a user can open aWindow showing the item's tag information and can view and/or change taginformation.

According to another aspect of the invention, each volume can includeone or more folders. A folder may be configured to be a view of thedatabase and include pointers to the files associated with that view.This enables the contents of a folder to be constructed and maintaineddynamically. According to another aspect of the invention, variousfolder types may be used. By way of example, the folder types mayinclude one or more of a query folder, a search folder, a merge folder,a magnetic folder, a typed folder and other types of folders.

A query folder is a folder that generates a query (e.g., based on thefolder name or based on a tag attached to the folder, or otherwise) intothe file management database. A query folder encapsulates a set ofsearch criteria and includes real-time-updated results of the search. Ifa file is later changed so that it matches the query, it will be addedto the corresponding query folder. Similarly, if a file is later changedso that it no longer matches the query, it will be removed. The searchcan be a full-text search across one or more volumes, or it can be a tagsearch, where the query searches tags that have certain values. Othersearch techniques may also be used. Matching objects are then associatedwith that query folder.

A search folder is a folder that has associated with it search criteriafor searching contents of files or other digital objects. Matchingobjects are then associated with that search folder. According to oneaspect of the invention the volume manager supports integration withfree-text search software. When any application changes the contents ofa file (or folder), the normal sequence is for the file to be opened,written to, and then closed. The volume manager processes each of theserequests. When it determines that a file has changed, a sequence ofactions is processed. One of these actions can include queuing the fileto a search engine for indexing. In a similar way, immediately after afile is erased, a request to remove the file from the index is queued tothe search engine.

According to one embodiment, the system recognizes folders withspecially formed names, or with special tags, as being search folders orquery folders. When such a folder is recognized, a search string isextracted from the folder name or from specific tags, and passed to asearch engine. The results of the search are shown as familiarfiles-in-folders. If the search query is presented in the form of afolder name or a tag value, it is persistent. The search strings caninclude complex search expressions, including boolean operations. When afile is created or is changed so that it matches an active searchfolder, the name of the file will appear in that folder without anyadditional intervention by the user. Files can also be specially markedto prevent indexing. Other aspects of searching are facilitated by theinvention.

A merge folder is a folder (or overlay) that combines two or morefolders (e.g., using boolean logic or otherwise). A merge folder caninclude items from a ‘merge list’ of other folders. An item in a folderin the merge list hides a like-named item in a folder farther down inthe merge list. According to one embodiment, the merge is real-time, nota snapshot. As items appear and disappear in the merged folders, theyappear and disappear in the merge folder contents. A merge folder can beconfigured to allow creation of new items in the first folder in themerge list, and it can be configured to allow the system to delete itemsfrom where they reside or merely to hide them from appearing in themerge folder. Items from the source folders can appear in the mergefolder as sync links. Preferably, the system uses a combination of queryfolders and merge folders to implement one form of complex queries.

A magnetic folder “attracts” files with certain tag values. For example,magnetic folders disable automatic removal if a file ever matches aquery or other criteria.

Typed folders are folders that include files or other content that havecertain characteristics. For example, a typed folder can limit whattypes of files can be located in the folder (e.g., only PDF files), itcan prevent certain types of files from being located in the folder andcan require certain content. For example, a ‘Group Role’ folder can beallowed to include only ‘User’ files and ‘Group Access’ folders.

According to another aspect of the invention, changes to folders andfiles are handled on a transactional basis. This enables the system toretain information regarding the creation, modification, and uses of afile or its attributes, maintains information regarding relationshipsbetween files, controls access to files based upon the storedinformation and provides other advantages. This aspect of the inventionfacilitates an item history feature. Each time an item is copied, moved,deleted, saved, renamed, etc., the volume manager keeps a record of oneor more of what was done, by whom, when, why and other desiredinformation. This information may be seen by choosing an item (e.g., byright-clicking the item from the user interface) and selecting “ShowHistory.” In some embodiments, this brings up a window that shows one ormore of where this item was copied from and to, who did it, when, whyand other desired information. The Item History for a folder can alsoinclude a list of items that used to be in the folder but which wereeither deleted or moved from the folder. The user can open and explorethese items if desired (they will be frozen as discussed below). Theseitems can be selected by selecting ‘Undelete’ or ‘Bring back’ from amenu.

An ‘undo’ option lets a user undo other previous commands. When a userright clicks on a file or folder and selects the ‘Undo . . . ’ menuitem, this brings up a dialog box that describes a list of things doneto the item and the option to undo one or more of them. The undo featureapplies to whole folder hierarchies as well as to individual orcollections of files. Other changes to files and folders can be viewedand undone in accordance with the present invention.

The system further permits a user to select a ‘Show versions’ menu item.This displays all extant past versions, which are all frozen. The usercan drag these versions to somewhere, open them, compare them with otherversions, or perform other file operations. They are just files andfolders (except they're frozen). To make a previous version become thelatest, most current version again, the user can right click on an oldversion and select the ‘Make Current’ command. The item will then bereinstated as the current version.

These features facilitate simple tasks like undeleting a file but alsoprovide a broader range of novel features including the ability to undoa renaming of a file or folder and other changes made to the file orfolder.

Another feature accessible from the user interface is the ability tofreeze files or folders. When a file is frozen, both the contents of thefile and the tags attached to it are made permanently read-only. A fileor a folder and all of its contents (recursively) can be frozen. Whenthis occurs, no one, not even a super-user or administrator can make itmodifiable. Yet it can still be read. When an item is frozen, the usercan be assured that the item is truly a snapshot taken when it says itwas taken and that everything in it is as it was, nothing added, nothingchanged, nothing removed.

According to one embodiment, every file has an inspectablecryptographically-strong hash code (using the SHA-1 algorithm, forexample). The user interface permits verification so that this hash codecan be used to verify that the content really is intact, and that noerror or hacking has changed the content. The hash code may also be usedfor digital signatures.

Another aspect of the invention relates to versioning and saving. Thesystem permits saving a file from an unmodified application, or a usercan choose the ‘Save as Version’ menu item. The ‘Save as Version’command takes a snapshot of an item by making a copy of it, freezing thecopy so it will never change, and associating it with other pastversions of the item. A user can access any past version and copy it,link to it, or move it, but it can't be modified, since it will befrozen. When a snapshot is performed, the volume manager also recordswho, when, and optionally, why (if a user chooses to supply a comment orhave the system do so automatically). Taking a snapshot of a folder issimilar except that the volume manager saves a frozen copy of everythingunder the folder.

Another aspect of the invention relates to event driven actionsincluding triggers and constraints. Anything done to a file or a foldercan be an event that can trigger an action. A constraint can be arequired event or condition that must occur or exist before a certainaction can occur. For example, it can prevent a file from beingpublished before certain approvals are obtained. Numerous other usesexist for triggers and constraints. To use this feature, a user canselect from many pre-programmed actions and customizes them with dragand drop and form-fill-in. In some embodiments, actions can beprogrammed by the user. The combined result of all programmed actionsenables the system to react in real time. As an example, the system usesevent-driven actions to notify the right people when a work product fileis ready for them to review or to use in some other part of a project.Using event-driven actions, a user can build complex workflow automationinto folders and files.

Another feature of the user interface is the ability to easilymanipulate lists. According to this aspect of the invention, in listview, a user can sort by column as usual, but in addition, can configureany column to show the contents in ‘my order’. When the folder displayis in this mode, a user can rearrange the order of folder items usingdrag and drop techniques. The folder subsequently remembers the user'sordering.

Various aspects of the volume manager and coherency manager facilitatevarious other aspects of the invention. One such aspect of the inventionrelates to smart copies. The volume manager eliminates many scenariosthat would have necessitated making copies. The primary scenario where atrue copy is useful is where a user wants to modify one copy in one wayand another copy in another way. For these and other reasons, the smartcopy feature of the volume manager encompasses several enhancements overtraditional file copies. According to one embodiment of this aspect ofthe invention the system permits live copies, deferred copies and otherprovides other copy-related benefits.

According this aspect of the invention, when the system makes a livecopy of a file named A to a file named B it makes both A and B refer tothe same underlying file. If a user modifies file A, file B reflects thechange immediately. Deleting file A or B has no effect on the otherfile. If a new version of one file is made, then the other filename willrefer to that new version. The coherency manager permits live copies tobe on different volumes. Live copies can refer to folders as well asfiles.

The live copy feature facilitates organization of data, in part, becauseit lets a user put the same file or folder inside more than one folder.For example, a photo can be in both the Yosemite folder and the Janefolder. In reality, the folders each include a reference to the samephysical file. So if the photo is changed, the change will be reflectedin the “copy” in each folder.

Another aspect of the invention relates to deferred copies. When thesystem makes a “regular” copy of an original file named A to a copynamed B, the volume manager knows that the names refer to copies of thesame file. This uses only a small amount of additional disk space.Initially both the original item and the “copy” share the same data.However, at the time that a user modifies either the file called A orthe one called B, the volume manager will make a copy of the singleunderlying file, and each of the two names will refer to its ownseparate data. This applies to files, folders and other items. In thecase of folders, only when files are modified in one or the other copydoes the volume manager actually need to allocate space for the new,modified copy.

After copying file A to a new file B, very little additional disk spaceis needed because of the deferred copy feature. File A will rememberthat it was copied to file B, and file B will remember that it wascopied from file A. This information can be seen in the user interfaceand it can be used to navigate from one copy to another. File A and fileB share the same list of previous versions. If we modify A and then alsomodify B, the current versions will differ, but both still share all ofthe same previous versions. Normally, when a file is copied, the copy isassociated with the same current version and all the same previousversions. But if desired, a user can copy a past version of A to a newfile C, and then modify C. Now A and C differ, but the ancestry theyshare is the same up to the point where the copy was made.

Another aspect of the invention relates to smart links. Windows hasshortcut files. Mac OS has alias files. Unix has symbolic links and hardlinks. The invention supports these features and more. A link is areference to whatever is at the end of the given path. The path can berelative, absolute, or it can be a URL. With adequate permissions, auser can make the link “sticky.” A sticky link gets to dictateattributes of what it points to: the file type (such as a PDF file),whether there has to always be something there at the end of the path,and whether the link will adjust to point to the new location if thereference moves. A link can be configured to behave like a Mac OS alias,Windows shortcut, or Unix symbolic link or hard link, appropriate to theplatform from which it is accessed. A link can also be configured tokeep a cached copy of whatever was there the last time the link wasused. The link might include a cached copy of a remote web page or afolder on a remote web site, for example.

Another aspect of the invention relates to a smart caching feature. Whena user accesses volume A on server X from client machine Y, the volumemanager on machine Y creates an entry for volume A in its local diskcache. From then on, even if the user disconnects from server X, he canstill work on volume A from their client machine Y, using whatever iscached locally. Preferably, the user can request that certain files fromvolume A will always be cached on their client machine, in case theydisconnect or in case the server goes down. To do this, the user canselect an item on volume A, right click, and then select the ‘Keeplocal’ menu item from a pop-up menu. If the user sets ‘Keep local’ on afolder, all of that folder's contents, recursively, are affected. If theuser also wants to protect against the item being deleted, the systemcan make a Live Copy.

The volume manager on client machine Y works unobtrusively in thebackground to ensure that ‘keep local’ items remain in sync with theserver. If the user disconnects Y from the network then reconnects, thevolume manager will synchronize the cache with the server. If the usermade any changes in the local cache while disconnected, there may beconflicts with changes on the server. In this case, the user interfacewill help the user reconcile differences. The user interface'scompare-merge tools facilitate this.

Another aspect of the invention relates to a smart back up feature. Thevolume manager handles backups in an automated way. As files arechanged, they are sent over the network to another machine running acopy of the volume manager, which has been designated as the ‘backupserver’. The versioning features make a volume an ideal store forbackups because it has adequate expressive power to accurately representthe history of the backed-up data. Also, the system's transactionalcharacteristics are ideal for backup because the backup can beguaranteed to be a consistent snapshot.

Backups happen continuously, slowing down only when there's nothing todo or to get out of the way while a user is using his computer. Wheneverthere is idle time, at night, at lunch, while a user is on the phone,backups can go at full speed.

To arrange for backup of a folder, the user right-clicks on the folderand selects the “Backup . . . ” menu item. The user then designates afolder on another volume where he wants there to be a redundant copy ofthis folder and its versions from now on. Features in the user interfacewill assist the user in locating a volume manager on their network thatis an appropriate receptacle for their backups. Such a machine wouldoften be (but does not have to be) a dedicated, unattended server(called a ‘backup drone’), shared by multiple users. The user interfacewill also help the user identify an appropriate place to store theirfiles on the backup machine. For example, there could be a specific partof the backup machine's folder hierarchy that has been designated forbackups. Typically, the folder being backed up will be the root folderof a volume. The backup drone will generally be up and connected 24×7.It may have RAID disks, it may be a member of a Cluster, and it may inturn back up to another drone off-site.

Backups are useful for at least two classes of problems: disasterrecovery and undo. Disaster recovery is easily handled by copying anentire folder or volume from backup as of the most recent backup. Undoallows a user to retrieve deleted items and past versions of modifieditems. As discussed earlier, undo of recent deletions and modificationsdoesn't require backup, since the volume manager keeps recent versionson the local disk. Eventually, however, enough old versions mayaccumulate on the local disk that the volume manager will need to deletesome of them, counting on a backup volume to supply the data if it'sneeded. If an undo involves data that has been deleted from the localvolume, the user interface transparently retrieves the needed data fromthe backup volume. The undo operation is a little slower, but otherwiseoperates similarly.

As can be seen, these various features, functioning together, permitgreat synergy and provide unique functionality not heretofore believedto be known. By way of example, the freezing feature is particularlybeneficial to reliably storing past versions. The deferred copiesfeature makes the folder snapshot feature practical because it requiresminimal disk space. Another useful versioning feature is the ability toview a folder hierarchy or an entire volume as of a given time. This ‘asof’ view uses frozen items. Various other synergies exist.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates complexity in access control associated with aconventional system.

FIG. 2 illustrates a server system that can utilize a file managementsystem according to an embodiment of the present invention.

FIG. 3 illustrates various components of a file management systemaccording to an embodiment of the present invention.

FIG. 4 illustrates communications in a file management system accordingto an embodiment of the present invention.

FIG. 5 illustrates a block diagram of a file management system accordingto an embodiment of the present invention.

DETAILED DESCRIPTION

FIG. 2 illustrates a computer system 100 to which the file managementsystem of the present invention can be applied. As illustrated in FIG.2, the computer system 100 includes a server 110 and a terminal device120. The terminal device 120 may be a computer. Alternatively, it may beany other device which can communicate with the server in order toaccess files, such as a PDA, a MP3 player, a cellular phone, aelectronic gaming system, etc. The server 110 includes at least onememory volume 111 and at least one volume manager 112. The terminaldevice 120 is connected to the server 110 by wired or wirelesscommunication link 130 in order to access data on the server 110. Thecommunication line 130 connects to the volume manager 112 in order toaccess the memory volume 111 on the server. Alternatively, the terminaldevice 120 may include its own volume manager 121 for directly accessingthe memory volume 111 on the server 110. Preferably, the volume manager112 is a software application operating on the CPU of the server whichprovides functionality as discussed below. Alternatively, the volumemanager 112 may be implemented in hardware or operate on a machineseparate from that having the memory.

FIG. 3 illustrates components of a software application providing thefunctionality of the file management system according to an embodimentof the present invention. The file management system includes a userinterface 210, a volume manager 220 and a coherency manager module.Other software modules may be used and functionality described herein asbeing performed by one module may in some cases be performed in whole orin part by another module. The various software modules may be installedon each computer or other device which utilizes the file managementsystem of the present invention and on one or more servers or centralcomputers. These software modules may operate in conjunction withexisting software on those machines. In particular, the user interface210 and the volume manager 220 function in connection with the existingfile system on the computer, for example, a Windows file system 251. Theuser interface 210 includes at least one of two alternative components:a set of plug-in extensions 211 to Windows Explorer 250 (or other suchapplication) and a separate user interface application 212. The plug-inextensions 211 allow users to access the functionality of the novel filemanagement system utilizing familiar formats and displays (e.g., withina Windows Explorer or other environment). The user interface application212 provides an alternative interface and may include additionalfunctionality. Also, the user interface application can be used fordevices which do not include Windows Explorer.

In one embodiment, a volume is a unit of file storage typicallyassociated with a disk partition, or with a Windows ‘drive letter’. Thisembodiment utilizes specific memory volumes created for use with thefile management system. In some embodiments of the invention, a memoryvolume 111 within the present invention can be a physical volume,residing on a disk partition initialized for use with the filemanagement system. In other embodiments, memory volume 111 may be avirtual volume whose data is stored inside a hidden folder on anexisting OS volume, such as NTFS 252 in a Windows file system 251. Thevolume manager 221 manages the contents of one or more memory volumes111.

The volume manager 221 may be enabled for network access. A proprietaryprotocol is used to communicate with the volume manager 221. FIG. 4illustrates the components of a file management system enabled fornetwork access. A TCP/IP connection is used to communicate with thevarious components operating on the memory. The volume manager 221connects to a client over a TCP/IP connection, using a unique fileprotocol. A Windows file protocol 254 may be used to communicate with aWindows file sharing application 253 for control of data not within thefile management system of the present invention. The protocol may beimplemented in Extended Markup Language (XML), with variations andenhancements that include HTTP, Java Remote Method Invocation (RMI) andraw binary streams. The protocol stream may be compressed and/orencrypted. A group of servers may be used to replicate the same data andappear to users as a single server, to provide high availability andimproved throughput.

The volume manager 221 operates on the memory volume 111 to providecertain functionality. The user interface 210 allows a user to accessthe functionality. The volume manger 221 is able to provide thefunctionality through specific control of information in the databaserelating to the memory volume 111 and through synchronization andlinking processes. The functionality of the volume manager 221 isdescribed below.

According to one embodiment, the volume manager 221 may create livecopies of files. A file named A can be live copied to a file named B,and then either file A or file B can be live copied again to a filenamed C. The underlying data referenced by the three different filenamesis the same. So a change to any one of the files will result in thosechanges being immediately visible through any of the live copies.However, deletion of one copy does not delete any other copies. The livecopies are associated in the database of the volume manager 221.

According to one embodiment, the live copies can be located in differentfolders. Thus, multiple copies of files can be organized in differentmanners while maintaining the same content. Since all files are managedby the volume manager 221, live copies also can be located in differentvolumes. Additionally, live copies are not limited to files. Folders mayalso be live copies. A folder named X can be live copied to folder namedY. Thus, folder X and folder Y would reference the same underlying dataobject. This has the effect that changes to folder X would immediatelybecome visible through folder Y. This includes adding new files to thefolder, renaming files included in the folder, or deleting files fromthe folder.

The volume manager 221 saves disk space and gains performance byutilizing deferred copies. According to one embodiment, when a “regular”copy is made of a file or folder, the file or folder's contents are notimmediately duplicated. Only a small amount of additional disk space isneeded for the information in the database regarding the new files orfolders. Both copies share the same data. Only after the data in one ofthe files is modified, does the volume manager 221 create separate data.The same applies to copies of an entire folder hierarchy: only whenfiles are modified in one or the other copy does the volume manager 221actually allocate space for the new, modified copy.

According to one embodiment, the user interface 210 can be used to tellthe volume manager 221 to freeze a file. Once a file or folder isfrozen, no one, not even a super-user or administrator, can modify orchange the state of that file or folder. Thus, frozen files provide asnapshot of the file as of the indicated time. Furthermore, every file,including those that are frozen, has an inspectablecryptographically-strong hash code (using the SHA-1 hash algorithm, forexample). The hash code can be used to verify that the content really isintact, and that no error or hackery has changed the content. The hashcode may also be used for digital signatures.

A file's hash code can also be used to identify identical content.According to one embodiment, the volume manager may identify files withidentical content, and link them together as deferred copies, therebyallowing the duplicate disk space to be freed.

According to one embodiment, the frozen file feature provides a simplemechanism to maintain prior versions of files. Utilizing a version savecommand in the user interface 210, a deferred copy of the file iscreated and frozen so it will never change. The frozen file is thenidentified in the database as a past version of the file. A past versionof a file can be accessed to copy, link to or move it. However, itcannot be modified. When a version is saved, the volume manager 221 mayalso store additional information about the version, such as when and bywhom it was saved. Also, comments about the version can be entered andsaved by the volume manager 221. In a similar manner, a folder can alsobe saved, which preserves a frozen copy of everything in the folder.

Because information about associated files, such as versions, is storedin the database, accessing associated files is simple. A “show versions”option can be selected in the user interface 210. In some embodiments, awindow will then display all extant past versions, which are all frozen.Any of the prior versions can be moved, opened, compared to otherversions, or otherwise manipulated without changing the content of theversion. Since information is stored about the timing of versions of allfiles, the volume manager 221 can provide a view of a folder hierarchyor an entire volume as of a given time. All of the parts of that vieware prior frozen versions.

A similar information for copies of files may also be maintained. A“show copies” option may be selected from the user interface 210. Insome embodiments, a window will then display a copy pedigree for aparticular file. Such a copy pedigree may include all predecessor files,all descendant files, or some combination. As with versions, any of thecopies can be moved, opened, compared to other copies, or otherwisemanipulated without changing the content of the copy. Since informationis stored about the timing of copies of all files, the volume manager221 can provide a view of a folder hierarchy or an entire volume as of agiven time. This allows users to view the migration and evolution of aparticular file as well as identify the source of the particular file.

Every time changes are made to files, the volume manager 221 recordswhat was done. When a file is copied, moved, deleted, or saved a recordis made. The system can then provide a history of any item, which showswhere this item was copied from and to, who did it, when, and why. For afolder, the history includes a list of items that used to be in thefolder but which were either deleted or moved from the folder. From thehistory list, items that have been moved or deleted can be restored,brought back to the folder, or copied back to the folder.

The volume manager 221 also provides linking capabilities. A link is areference to whatever is at the end of the given path. The path can berelative, absolute, or it can be a URL. In some embodiments, a link canbe “sticky,” in that it dictates attributes of what it points to. Forexample, the link can include a reference to a file type (such as a PDFfile), whether there has to always be something there at the end of thepath, and whether the link will adjust to point to the new location ifthe referent moves. A link can be configured to behave like a Mac OSalias, Windows shortcut, or Unix symbolic link or hard link, appropriateto the platform from which it is accessed. A link can also be configuredto keep a cached copy of whatever was there the last time the link wasused, for example, a web page or a folder on a web site.

The volume manager 221 also provides functionality with respect tofolders. One type of folder implemented by volume manager 221 is a queryfolder. A query folder can be created which encapsulates a set of searchcriteria and includes real-time-updated results of the search. Thesearch can be a full-text search across one or more volumes, or it canbe a tag search.

Query folders are stored in the volume manager 221 like ordinaryfolders. However, their uniquely formatted name or a special tagattribute indicates to the system that they are query folders and notregular folders. At the time that a query folder is enumerated, thequery is processed, and the selected files are listed as being thecontent of the folder. In addition, when a new file is created, or whenone of the tags associated with the query folder changes, the query isevaluated again, and an event is delivered to the client to indicatethat a file should be added to or removed from the query folder.

Another type of folder implemented by volume manager 221 is a mergefolder. A merge folder includes items from a ‘merge list’ of otherfolders. An item in a folder in the merge list hides a like-named itemin a folder farther down in the merge list. The merge is real-time, nota snapshot; as things appear and disappear in the merged folders, theyappear and disappear in the merge folder contents. A merge folder can beconfigured to allow creation of new items in the merge folder so thatthey reside in the first folder in the merge list. A merge folder canalso be configured to allow deletion of items from where they reside ormerely to hide them from appearing in the merge folder. Items from thesource folders appear in the merge folder as live copies. A combinationof query folders and merge folders can be used to implement complexqueries.

Merge folders are also stored in the volume manager 221. The underlying“source” folders know about each merge folder they are used by, and arealso referenced by the merge folder. This allows the system to propagatechanges in the source folder to the merge folder. The system can alsowarn the user about a potential conflict before a source folder isdeleted. The merge folder also includes a list of edits that are appliedto each of the source folders. If a file is deleted from a merge folder,for example, an edit is stored so that after the contents of allreferenced source folders are collected, the edit list is applied, andthe deleted file is removed from the enumeration before the final listis passed back to the user interface 210 for display to the user.

One aspect of the invention provides version control. A folder can bedesignated as a “Repository.” In one embodiment, a repository folderrequires that changes be made by doing a “drag-update” to the top-levelrepository folder itself- other changes to its contents (i.e., a pieceat a time) are not allowed. To “check out a copy,” a user makes a“regular” copy of the repository folder. Because of deferred copies,this operation is very fast. Users make whatever changes they need tomake anywhere within in the copy of folder. Then the copied folder isdragged and dropped back to the repository folder. The user interfacepops up a “check in” window that asks the user to include a note aboutthe changes that were made. During the check-in process, the volumemanager compares the version history of the new files with the versionsthat are already in the repository. This comparison allows it toidentify conflicts. The user interface compare-and-merge tools are usedto resolve any conflicts that may have arisen as a result of anotheruser checking out the same hierarchy and changing any of the same files.

The file management system of the present invention allows folders, aswell as files, to have type. The type is stored in the database with theappropriate folder information. A type can configure a folder to limitwhat can be in it and to optionally require certain contents. Forexample, a ‘Group Role’ folder is allowed to include only ‘User’ filesand ‘Group Access’ folders, as discussed below.

The listing of items in a folder is greatly enhanced by the filemanagement system of the present invention. Any of the additionalinformation stored with respect to files can be saved. Furthermore,special orderings of files can be used in displaying a list. The itemsin folders can be sorted by their name, size, modify time and certainother information, as in most file management systems. However, the usercan also configure the user interface 210 to display tag names andvalues associated with the files in a folder. When the folder display isin this mode, the tags appear as column headings, and the tag valuesappear in those columns. The files can then be sorted based on those tagvalues, by clicking on the tag name at the top of the column. This isimplemented in the user interface 210 as an extension to WindowsExplorer known as a “Namespace Extension.” The extension is told thename of the folder that it should display. It then sends a request tothe volume manager 221 for a list of all of the tags used in thatfolder, and the value of each tag for every file in the folder. It usesthat information to render the user interface 210 as described above.

The system can also display the date and time when an item was added toa folder, not just when it was created.

When applied on a network, the file management system is able to cachefiles for improved access while maintaining control. When a servervolume is accessed, the volume manager 221 on the client creates anentry for the server volume in its local disk cache. From then on, evenif disconnected from the server, the client can change anything thatappears to be on the server volume, using whatever is cached locally.The system can also ensure that certain files from the server volume arealways cached on the client, in case the client is disconnected or theserver goes down. If a user wished to always have an item available, the“keep local” option is selected from the user interface 210. For afolder, all of that folder's contents, recursively, are affected whenthe “keep local” option is selected. If a user also wants to protectagainst the item being deleted, they should make a live copy. The clientvolume manager and the server volume manager work unobtrusively in thebackground together with the coherency manager to ensure that ‘keeplocal’ items remain in sync with the server. If the client isdisconnected from the network, the coherency manager will orchestratesynchronization of the volume manager with the client cache uponreconnection. If changes have been made in the local cache whiledisconnected, there may be conflicts with changes on the server. In thiscase, the user interface 210 will work with the user to reconcile thedifferences. This is done in part through a set of compare-merge toolsthat are integrated into the user interface 210. These tools allow theuser to visualize the changes, and to either select the right version ormerge changes from one file into another.

Since information about all changes to files and folders is maintainedby the volume manager 221, undoing actions is fairly simple. The“Undelete” option in the user interface 210 first provides a listing ofdeleted items. While files are still deleted, they can't be viewed ormodified. When the desired file or folder is selected, the undeletecommand from the user interface 210 makes it viewable and modifiableagain. Similarly, the same process can be used to reinstate a previousversion of a file from a version listing. Also, the various actionstaken with respect to a file or folder can be viewed and be reversedwith the “undo” option.

Any change to a file or a folder is an event that can trigger anotheraction by the file management system. Many pre-programmed actions can beselected and customized with drag and drop and form-fill-in actions.Actions can also be programmed as one would in a spreadsheet, usingJavaScript, Java, or Visual Basic. The system can react in real time,similar to a recalculation of a spreadsheet when a cell is changed.

In some embodiments of the invention, every item in the memory volumehas tags. A tag is a coupling of a tag type and a tag value. There aremany built-in tag types, such as text, user, date, and icon. A tag canbe added to an item, perhaps creating a new tag type in the process, andits value can be modified (except for some built-in “system” tags).

An email integration package allows email messages to be brought intothe system to be manipulated as files in folders and also to beassociated with files and folders. To determine whether there has beenany email discussion about a file, right-click on the file and selectthe “Messages” command. The user interface will then provide the emailhistory associated with this file. By clicking the “New Message” buttonon the window toolbar, the user may select the people to whom they wantthis message to go (the system knows who's participated in thediscussion so far). The user's usual email application (such asMicrosoft Outlook) opens up with a new message in it, and in the body ofthe message there is a special URL with a special protocol (such as“itc://”) that refers to the file being discussed in the email.

Because the present invention is a peer-to-peer system, any user of thesystem reading the messages including “itc://” URLs can navigate easilyfrom the message to the referenced file—not a copy, but the identicalfile in the space shared by the peers.

In fact, the URL in the message refers to a specific version of thefile, the version that was current when the email was written. If theURL is opened, the user interface brings up a Windows Explorer window tothe folder that includes the file, selects the file, and opens a“choices” window. The choices window offers to show other emails aboutthe file, to show the file as it was when the email was sent, or if thefile has been revised since then, the system shows the version historyand allows a selection between the URL's version and the current versionand offers to show a comparison of the two versions.

The system provides access control through use of management folders. Inone embodiment, every volume has a management folder with twosubfolders: users and tags. The file management system grants access toan item (file or folder) based on who the user is and the groups towhich the user belongs. There are three kinds of typed folders found inthe users subfolder: “group”, “volume group”, and “group fromauthentication server” (the latter two are subclasses of folder type“group”). These folders can include other group folders and specialfiles of type “user”.

The system may rely on one or more designated outside authorities toauthenticate users. This authority can be the local computer, a WindowsActive Directory server, a Kerberos server, LDAP, etc. For everyauthentication source, there is a corresponding typed folder of type“volume group.” For each user authenticated by that source, there is acorresponding user file in the folder. The user file is an XML file thatincludes authentication source information and user details, such asfull name, phone numbers, etc. For each group maintained by theauthentication server, there is a typed folder of type “group fromauthentication server” in which there are live copies of all the usersthat are members of the group. For example, if the system has beenconfigured to use the Windows domain Active Directory server calledCORPORATE, the users area might include these:

-   /users/corporate/Ron-   /users/corporate/Jane-   /users/corporate/Fred-   /users/corporate/admin/Fred

The /users/corporate/ folder (which is a typed folder of type “group ofauthenticated users”) and everything under it includes information thatidentify the CORPORATE Windows domain as their source. The/users/corporate/admin/ folder is a typed folder of type “group fromauthentication server”, and the user file Fred in it is a live copy of/users/corporate/Fred (because files represent the same data). A typedfolder of type “volume group” is a convenient way to establish groupsusing the user interface. These groups are known only to the system, notto the authentication source. They can be useful because they allowgroups within groups.

An authentication group folder is special in how it treats the userfiles and group folders included in it, and it allows only those typesof items in it. Unlike traditional systems, the present invention allowsa group to include other groups as well as users. The live copy featuremakes organizing users and groups easy. Each item (folder or file) hasone or more owners. An owner is a user or group. An owner is allowed tochange access settings for itself and for other users and groups.

The system uses event-driven actions extensively, and custom actions canbe established to do simple but powerful things. For example, the systemcan notify the right people when a work product file is ready forreview. Using the event-driven actions, complex workflow automation canbe easily built into the user's everyday work area, folders and files.

The system tracks various aspects about the usage of files and foldersby users. Furthermore, it can be customized to ask for more specificinformation. Typical document management systems are limited becausethey are not able to control the files on users' desktop computers.Users often have to extract files from the document management systemonto their desktop computer (thereby out of reach and out of the controlof the document management system) and then back into the documentmanagement system at some later time. According to one aspect of theinvention, files never leave the system.

The present invention eliminates bad copies in a variety of ways. Forexample, in a conventional system, a user may wish to copy an item froma server or a CD-ROM to the user's local machine. If the user's purposefor making the copy is convenience, the invention provides a sync linkfrom the item on the server to the local volume. If the user's purposeis for speed of access, the invention may provide a cached copy on thelocal volume. If the user's purpose is to protect against the servergoing down or the item being deleted from the server or unavailabilityof the CD-ROM, the invention may provide a live copy of the item on thelocal volume. If the user's purpose is to have access to the item whennot on the network, the invention provides the keep local feature.

In other examples, the user may wish to copy an item from the localmachine to the server or a removable disk. If the user's purpose formaking the copy is for backup, the invention provides automatic backupto the server. If the user's purpose to publish the item for others toaccess, the invention provides a live copy on the server and furthermoremay provide permissions to control which users have access. If theuser's purpose is to capture and maintain a version, the inventionprovides the snapshot feature.

In other examples, the user may wish to copy an item from one folder toanother folder for organizational convenience (i.e., have all relatedfiles in one folder). In this case, the invention provides live copiesor alternatively, special folders that have links to the various itemsthat should be included therein.

In another example, the user may wish to copy items to a zip file orother archive format for reasons similar to those described above. Ifthe user's purpose is to keep a snapshot of a current version of theitems, the invention provides the freeze or save features. If the user'spurpose is to send these items to another user, the invention provides alink to the saved version that then can be forwarded to the other user.If the user's purpose is to send these items in a zip format, theinvention provides an “extract as . . . ” folder feature.

FIG. 5 illustrates a block diagram of an embodiment of file managementsystem in further detail. As illustrated therein, file management system500 interfaces with a file system interface 502. File system interface502 allows file management system 500 communicate with other systemdevices (not illustrated) using various protocols. In one embodiment ofthe present invention an SMB protocol interface box may be used. As isknown, SMB is a standard protocol used, for example, by Windows toimplement file sharing. With the SMB protocol interface box, filemanagement system 500 appears like a network drive to other systemdevices. As would be apparent, other interfaces could be used includingthose that would support different file-access protocols or that wouldallow file management system 500 to appear as a native file system.

File system interface 502 provides a standard API that functions toimplement standard file system calls, (e.g., read/write, open, close,etc.). File system interface 502 passes system calls that it receivesfrom other system devices to a disk adapter 504, (sometimes referred toherein elsewhere as a grok adapter) that redirects and implements thosesystem calls in accordance with the present invention.

In one embodiment of the present invention, disk adapter 504 implementssystem calls or “requests” such as those illustrated in request block506. These requests include: “list” which is used to enumerate a folder;“stat” which gets information about a particular file such as size,type, etc.; “mkdir” which creates a directory; “delete” which deletes afile, a folder, etc.; “open” which opens or creates a file; and “close”which closes a file. These are referred to herein as file systemrequests. Other requests such as “read,” “write,” “seek,” etc., may alsobe included as would be apparent and are referred to as file or “blob”requests. In general, the operation and use of these requests by othersystem devices are well known.

In one embodiment of the present invention, certain requests and inparticular, read and write requests, are actually diverted inside diskadapter 504 directly to streams that exist on an underlying file system508. In one embodiment, file system 508 is an NTFS-based file system.Other file systems such a FAT file system may be used as would beapparent. However, the NTFS files system provides a more robust systemwith some built-in integrity preserving capabilities than does FAT filesystems. Furthermore, NTFS more readily allows millions of files to belocated in a single folder.

When disk adapter 504 detects read or write requests, they are diverteddirectly to file system 508. In one embodiment, these requests do notpass through the remainder of file management system 500, in part, toavoid processing of large data streams, or “blobs,” by a transactionaldatabase. However, in other embodiments, for example, in those thatimplement a custom object store, these blobs may pass through the filemanagement system 500 in order to provide transactional integrity (i.e.,all transactions fully complete or fully fail) as will become apparentfrom the discussion below.

One aspect of file management system 500 is to manage all of themetadata that surrounds that blob as opposed to managing the blobitself. This metadata may include, for example, filename, tagsassociated with a file, a folder in which the file resides, a time ofits creation, a time of its last modification, etc. In some embodiments,file management system 500 may also manage blob creation (e.g., openinga zero length file) and deletion.

When a request from a file system arrives, disk adapter 504 creates arequest object that encapsulates any components of the request foroperation with a transactional database. In some embodiments of thepresent invention, this encapsulation allows file management system 500to be fully asynchronous in that it allows request objects to be queuedfor subsequent completion without tying up system operation. In someembodiments, disk adapter 504 creates a different request object foreach type of incoming request. In one implementation, each request(“list,” “stat,” “mkdir,” etc.) corresponds to a subclass of the baseclass “request.”

For example, a “mkdir” request object would encapsulate all of theparameters for the mkdir request including a name of the directory to becreated and a user name associated with the person requesting thecreation. The request object is then passed to a system call dispatcher507. System call dispatcher 507 passes the request object to a threadpool 510 to be executed. Thread pool 510, in turn, wraps each requestobject or each action associated with the request object inside atransaction for use with the transactional database.

In one embodiment, thread pool 510 includes a parallel set of objectsderived from the transaction wrapper. These parallel objects arereferred to as task objects. They are derived from another class ofobjects referred to as a transaction wrapper object. Thus, system calldispatcher 507 passes the request object to the task object which isthen handed off to a thread pool to be executed. One aspect of thisembodiment is that the task objects may sit in a queue while awaitingprocessing by thread pool 510. As would be apparent, thread pool 510also provides a mechanism by which file management system 500 mayasynchronously operate, thereby alleviating server overuse and providingimproved performance by minimizing connections to the underlying objectstore.

Thread pool 510 grabs task objects one at a time and calls a run methodassociated with the task object as would be apparent. This run methodwithin the transaction wrapper handles the object store transactions.More particularly, the run method calls a do_transaction method, whichis overridden inside these task objects. In this way, each of taskobjects does not require all of the external wrapper code that knows howto manage the transactions. The particular task object performs itsspecific task, (e.g., creates the directory by doing the appropriateobject manipulations) and then returns. So the transaction wrappercreates or starts a transaction, calls its specific do_transactionmethod, and then calls the commit transaction routine.

When two tasks or threads attempt to modify the same object(s), thetransaction database will detect it and prevent the transaction fromsucceeding by throwing an exception. The transaction wrapper managesthose exceptions, by for example, reattempting the transaction somenumber of times. In one embodiment, if the transaction continues tofail, the exception manager attempts to obtain exclusive access to thedatabase thereby blocking out any other transactions while it completesthe transaction.

Before discussing each of the task objects in further detail, a volumemanager object 515 and an object store 520 are described. According toone embodiment of the invention, volume manager object 515 manages muchof the non-persistent data that's associated with volume 525, whilevolume 525 stores the persistent data.

When disk adapter 504 is first initialized, it receives a volume namerepresenting a volume 525 and is instructed to initialize volume 525.Next disk adapter 504 opens volume 525 in similar fashion to aconvention file system mount command, by calling volume manager object515. During this initialization, disk adapter 504 calls a static methodinside volume manager object 515 to ask for an instance of volumemanager 525 associated with the volume name. The static method eitherreturns an existing volume manager object or creates one and initializesit. If the volume manager object exists, it's just looked up in a hashtable by the volume name and returned. If not, the volume manager goesout to the database, establishes a connection to the object store 520and does a lookup to see if a volume object has been stored there. If ithas been stored in object store 520, then that volume object is read inand stored in the volume manager. So where the volume object has beenpreviously created, mounting comprises either reading that volume objector getting a reference to that persistent volume object from the objectstore and storing a reference to that volume object in the volumemanager.

In one embodiment, object store 520 corresponds to an object store. Inthis embodiment, since each object reference is owned by a particularsession, it is not possible to pass a standard reference to an objectfrom one session to another. In this embodiment, object store 520provides a mechanism referred to as a shared object reference thatallows access to these persistent objects with references unique to eachsession. After the volume manager 515 mounts the volume 525, a referenceto the volume 525 is stored in a shared object reference in the volumemanager 515.

When the volume object does not already exist in object store 520,volume manager 515 creates volume object 525, causes it to beinitialized, and stores it in object store 520. When volume 525 isinitialized, a root slot is created along with a root folder and anumber of folders and tags associated with a tag volume.

Volume manager object 515 also manages access to sessions of objectstore 520. In one embodiment, a read/write lock is created and anchoredin the volume manager. Any class in file management system 500, forexample, transaction wrapper 510, starts a transaction by calling amethod in the volume manager to begin the transaction. Moreparticularly, the volume manager includes transaction begin andtransaction commit methods. When the transaction begin is called, thevolume manager must acquire a read lock before it calls the underlyingobject store begin transaction method.

A read/write lock provides for multiple readers. So while multiple readlocks can be acquired, only one write lock can be acquired. This lockoperates as follows. When a write lock acquire is called or issued, itsuspends or waits until all read locks have been released. Subsequentread lock acquires that arrive after the write lock acquire is calledare suspended until the write lock acquire completes and the write lockrelease completes.

In one embodiment of the invention, a read lock is acquired in thetransaction begin method and the read lock is released in thetransaction commit method. In this way, multiple threads and multiplesessions are allowed to be active at the same time. However, toaccommodate instances where a write conflict occurs such as describedabove, retry logic is incorporated into the transaction wrapper. Thusafter trying and failing to execute a transaction multiple times, thetransaction wrapper calls an exclusive begin method inside the volumemanager that calls a write lock acquire on the lock object that's usedfor the normal transactions. This has the effect of letting all of thenormal transactions that are in progress complete, at which point intime, that session gains exclusive access to the database, and it canthen complete its transaction without fear of interference from othersessions.

As mentioned above, one embodiment of object store 520 may comprise anobject store. In this embodiment, object store 520 stores Java objectsin a persistent store on disk using a sophisticated caching andpersistence mechanism. Object store 520 allows for multiple sessionswith each single session having a consistent view of the database. As asession begins a transaction, object store 520 creates a snapshot of thedatabase that remains consistent until the end of that transaction. Whenthe transaction commits, all of the objects changed by the transactionare written to the database in an atomic fashion using loggingmechanisms for recovery or rolling back.

In one embodiment of the invention, the volume manager provides ingeneral a one-to-one association between threads and sessions. Becauseeach session has a consistent view of the database, it cannot damagesome other session.

Most of the task objects discussed above include a path name as aninput. One function the file management system 500 performs is to mapconventional path names (e.g., c:/folder/subfolder/file.doc, etc.) intodatabase objects of various kinds. The volume manager 515 parses thepath name and performs various table lookups to identify a node object.The volume manager begins at a root object anchored in the volume objectand “walks” the graph of objects from the root down to the node object.The objects that the volume object is walking through while parsing areillustrated in FIG. 5 as file system data structures 530.

File system data structures 530 derive from a super class called filesystem node, or FS node, and include a slot object 532, an entry object534, and an item object 536 that includes a container object 537 and astream object 538. These objects in file system data structure 530represent files or other data structures that reside on a physical disk.

Slot object 532 manages a name of a file or a folder. Entry object 534manages tags and attributes. Tags are described in detail below.Attributes describe whether the file is frozen, read only, etc.Container object 537, which corresponds to folders, manages all of thedata structures associated with a folder. Stream object 538, whichcorresponds to blobs, manages all of the objects or all of the items orall of the pieces of data associated with a blob including, for example,the name of the blob on the native file system.

In one embodiment of the invention, each file or folder corresponds to atriple including a slot 532, an entry 534 and an item 536. Moreparticularly, each file corresponds to a triple of a slot, an entry anda stream 538, while each folder corresponds to a triple of a slot, anentry, and a container 537. The objects forming a triple are linkedtogether in various ways to achieve some of the aspects of the presentinvention including live copies and deferred copies.

Container 537 allows file management system 500 to map path namecomponents into slots 532. In some embodiments, container 537 alsoincludes information about whether or not deleted files should be shownwhen the folder is enumerated. In other embodiments, container 527identifies a type of the folder, for example, whether the folder is anormal folder, a query folder, or a search folder. Container 537 mayalso include maintenance data that takes a file or folder name and mapsit to a slot to facilitate certain types of lookups. Container 537 mayalso include methods within the container class that, for example,enumerate the folder

Stream 538 is relatively simple by comparison to container 537. In oneembodiment, stream 538 includes a string that identifies the name of thefile on the disk in file system 508 where the actual blob resides.Stream 538 may also include a hash ID. In one embodiment, this is acryptographically strong hash of the contents of the file. Each time afile is modified, this hash value is recalculated, to allow the trackingof identical files according to the invention.

Entry 534 manages any tags that are attached to a file. Since multipleslots 532 can refer to the same entry 534, the entry object alsoincludes a list of all of the slots 532 referring to that entry 534.This may occur, for instance, with hard links. Entry 534 may alsoinclude a reference to the underlying item 536, and references to arevision chain (e.g., the previous version to this one and the nextversion). According to one embodiment of the invention, each entry 534lives somewhere on a revision chain—it may be the only object on thatchain or one of many. In some embodiments, the revision chain is linear.In other embodiments, the revision chain may include branches that mayallow an entry to reside on any number of revision chains. In furtherembodiments, a similar mechanism may provide for a copy history thatrecords where this entry was copied to, where it was copied from, etc.Each entry 534 may also include one or more attribute flags including afrozen attribute, a repository attribute, a free text indexer attribute,and a read only attribute.

Entry 534 also manages a hash table that maps tag names to theircorresponding data structures as will be described in further detailbelow. Entry 534 may also include methods for manipulating revisionlists, for setting tags, for removing tags, for copying tags to anotherentry, and for updating dynamic folders.

File management system 500 also includes a tag object 540. Tagscorrespond to a name/value pair that is associated with either a file ora folder. As discussed above, entry 534 is the primary object to whichtags are attached. Because both files and folders have an entry object,they can both have tags. According to the invention, tag look-ups areused many different places and for many different reasons in the system.As a result, their implementation required speedy operation. In order toprovide the necessary speed, in one embodiment of the invention, all tagnames are stored in a large bi-directional hash table. In other words,the hash table allows the identification of all objects that have aparticular tag associated with them as well as the identification of alltags associated with a particular object.

In one embodiment of the invention, a hash table is anchored in thevolume object 525, and is used to look up all tag names. This hash tablereceives a tag name and returns a single name holder object 541. Nameholder 541 includes the name of the tag and a set of all of theassociated value holders 542 for that name. Value holder 542 includesthe value of the tag. In other words, name holder 541 includes the nameof the tag and value holder 542 includes the value of the tag. In oneembodiment of the invention, a single name can be associated with manyvalues.

Tags can be attached to either entry objects 536 or slot objects 532.Tags that are attached to an entry object are shared by all slots linkedto that entry. When referenced with respect to tags, slots and entriestogether are referred to as taggable objects. Tags attached to a slotare visible only for that slot. File names, for example, may be storedas slot tags, since they are different for each slot. File type and filesize may be stored as entry tags, since they do not change based on thename of the file or the folder in which it is located. Slot tags areidentified by the prefix “slot.” For example, “slot.name” includes thefile name. Most other tag names are attached to entry objects.

Each value holder 542 includes a value and a reference to a collectionof taggable objects (entry objects 536 or slot objects 532) that sharethat same name/value pair. This allows file management system 500, then,to easily and quickly determine which entry or slot object is associatedwith a particular name/value pair by iterating over the set of valueholders held by the name holder. In addition, this allows all of theentry or slot objects that are associated with a particular tag or anyvalue of a particular tag to be determined.

Using these data structures, a given tag name may be associated withmultiple tag values at the same time for each entry. For example, whileit is intuitive that a name can have one value for one file and adifferent value for a different file, a single tag name can also havemultiple values for the same file.

To accommodate a reverse process, a hash table is anchored in taggableobjects, whose keys are tag names, and whose values are sets of valueholder objects for each of the values that is referenced by thattaggable object. This allows file management system 500 to identify allof the tags that are associated with an entry or slot. Moreparticularly, the value holder object has a reference that points backto its corresponding name holder. So from a taggable object, all of thevalue holder objects can be determined which provides the values of thetags, and from those, the tag name and other files with the same tagname can also be quickly identified.

In addition to tags, file management system 500 includes mechanisms forcausing side effects to normal file system operations. These mechanismsare referred to as triggers. In one embodiment of the invention, atrigger 545 is implemented around various requests. The triggers can beinvoked before and/or after each of the various requests, for example,to veto the operation, to indicate or record that the request either isabout to happen or just completed, or to cause various more complexactions to take place, such as setting tags or creating new files orperforming operations over a network. Triggers may also be invoked ifchanges are made to various tags, either globally (regardless of thefile to which the tag is attached) or locally (only when the tag isattached to a specific file), as would be apparent.

In one embodiment of the invention, trigger 545 includes a close trigger546 and an email trigger 547. When a file is modified and closed, thenclose trigger 546 is invoked. When a file is moved from one folder intoanother, then email trigger 547 is invoked.

In one embodiment of the present invention, when close trigger isinvoked, it can call an external program whose purpose is to determinethe MIME type of the file. Volume manager 515 makes an initialassumption about the type of the file based on its file extension, basedon a list that maps an extension string to a human-readable file type,and another list that maps an extension to a MIME type. However, if afile's extension is not in those lists, the close trigger will call anexternal program that opens the file, reads the first few bytes, and,based on a set of rules, determines what the MIME type of the file is.

The output of the external program is captured and stored into two tagsin the file management system 500 referred to as system tags. Systemtags differ from other tags in file management system 500 in that theycannot be directly modified by users of file management system 500.According to one embodiment of the invention, system tags start with thekeywords “sys,” or “slot.sys” for slot tags. Thus, “sys.mime” and“sys.type” include the MIME type information—the actual MIME type isincluded in sys.mime and a human readable version of the MIME type isincluded in sys.type. As thus described, these two system tags aredetermined when the close trigger is invoked.

In some embodiments of the invention, when the close trigger is invoked,a request is queued for a cryptographic hash to be computed for thefile. As this computation is both CPU and I/O intensive, it is queuedfor subsequent background processing so as to not delay the closeoperation as would be apparent. In one embodiment, a single backgroundthread is used for computing these hashes.

In a similar manner, the close trigger may also queue a request to indexthe file. Indexing the file facilitates free-text search of the contentsof that file. In one embodiment of the invention, file management system500 integrates with a third-party free-text search engines referred toas Lucene, though other engines could be used as would be apparent.Indexing may also be done by a single background thread.

When an email trigger is invoked, an email may be sent to a user basedon various tags that are attached either to a file (for example, to sendan email when the file is modified), or that are attached to aparticular tag (for example, to send an email when the tag is modified).In some embodiments of the present invention, the contents of the emailare static. In other embodiments, the contents are fully configurablebased on other tags that could be read either from the file itself orfrom the tag volume.

When the email trigger is invoked, it evaluates various conditions anddetermines whether to send an email. For example, if a file is beingdragged into a folder, the email trigger may be invoked. The emailtrigger would determine the parent folder associated with thedestination of the file and determine whether the tags on that folderindicate that an email should be sent. If so, in one embodiment of theinvention, the email trigger includes code to connect to an email server(whose IP address is specified in a specific tag) and to deliver anemail thereto.

Different triggers may be called based on different system events, ashave been described. The name of the trigger may be specified in a tag.When the file management system 500 executes the trigger, it dynamicallyloads the trigger software, and calls it according to a predefinedinterface. In one embodiment of the invention, the triggers may be Javaclass files; a Java class loading mechanism is used to load thesoftware; and a Java interface is used to specify the standard callingconventions. For example, a file “file.txt” may have a tag called“trigger.tag.my.tag” set to the value “MyTrigger.” In this example,whenever the tag “my.tag” for “file.txt” changes to a new value, filemanagement system 500 loads a Java class called “trigger.MyTrigger” andthen uses the “Trigger” interface to invoke that code.

As mentioned above, the invention provides for placing tags on tags. Inone embodiment of the invention, this is implemented using a tag volumewhere all tags in file management system 500 are reflected as folders.In this embodiment, the tag volume itself corresponds to /volumeroot/tags/ and tags in file management system 500 descend from thisfolder. For example, if you have a tag referred to as “sys.tag,” withinthe tag volume, it would be reflected in the filesystem as a foldercalled /volume root/tags/sys/tag. According to one aspect of theinvention, “dots” in the tag name are replaced with “slashes” andappended onto a prefix for the tag volume. Each time a new tag iscreated, a corresponding folder under that prefix is also created.

However, deleting a tag from a file, even if it's the last occurrence ofthat tag anywhere in the system, does not remove the correspondingfolder from the tag volume. This allows users to construct a tag namingconvention hierarchy (taxonomy) regardless of whether those tags areused. The notion of applying a tag on a tag, sometimes referred to asmeta-tagging, is implemented within this tag folder hierarchy. Asdiscussed above, tags on tags or “metatags” may used to describe variousattributes about a tag. In one embodiment of the invention, metatags areapplied to the sys.file tag by using the previously described mechanismsto apply tags to the folder that corresponds to the tag in the tagvolume. For example, to apply the “tag.type” metatag to the tag called“sys.tag,” the folder /volume root/tags/sys/tag would be located orcreated and the “tag.type” tag would be applied to that folder.

Another aspect of the tag volume is that when a folder is deleted fromthe tag volume, the corresponding tag will be deleted from every filewith which that tag is associated. A similar mechanism may be used torename tags.

In some embodiments of the invention, attached to the tag nodes in thetag volume is a list in the form of a multi-valued tag. This listincludes all of the values that are associated with that multi-valuedtag, as well as markers (in the form of other metatags) indicatingwhether or not additional values are allowed.

File management system 500 includes a stream transaction block 550 thatincludes a hash transaction object 551 and an index transaction object552. These objects include requests that are placed on the hash andindex queues, respectively, that were described above. These objects andtheir corresponding queues are persistent to maintain consistency offiles and file modifications and to facilitate recovery from servercrashes.

In one embodiment of the invention, requests are added onto a queue byone session and pulled from the queue by another session. But asdescribed above, each session has a unique and consistent view of theobject store. Thus, one session viewing the queue within the context ofan object store transaction does not see another session updating thequeue. Once initiated, then, the hash transaction and index transactionobjects would not see new requests entering the queue. In someconventional systems, these objects would periodically abort theirsession thereby updating their view of the object store, in order to seeif new requests have arrived. This is a very inefficient solution.

According to one aspect of the invention, this problem is overcome byusing a parallel non-persistent semaphore to manage these objects andtheir respective queues. When volume 525 is mounted as described above,volume 525 determines a number of objects within each queue. For eachqueue, volume 525 releases a corresponding number of semaphores. Asthreads may only acquire as many semaphores as have been released, whena thread attempts to acquire a semaphore object and none are available,the thread waits until some other thread releases the correspondingsemaphore.

When, for example, a hash transaction thread begins, it first attemptsto acquire a semaphore object. If the thread acquires one, it knows thatthere must be a corresponding object in the persistent queue. The threadmay then join an object store session and start an object storetransaction. The thread then safely pulls an object off the queue andbegins processing it.

Correspondingly, after a new object is placed onto the queue and thecorresponding transaction is successfully completed, the thread thatplaced the object onto the queue releases the corresponding semaphore.

The semaphore mechanism thus described is important because typically,object store 520 does not allow one session to synchronize on objectsused by another session for this kind of “thread-to-thread”synchronization. If fact, some object stores throw an exception whenthat occurs in order to facilitate each session's unique and consistentview of the database.

Once an object is pulled from the queue, hash transaction object 551reads the corresponding file and passes the data to a routine thatcomputes a hash code. In one embodiment of the invention, this hash codeis a SHA-1 hash code implemented in Java as is known.

According to one aspect of the invention, once determined, the resulting160-bit hash code is encoded into a relatively human-readable characterstring. In one embodiment, the hash code is encoded into a 35-characterstring. In this embodiment, every five bits of the 160-bit hash codeencoded as an ASCII character. The five bits correspond to a 32 valuesfrom the ASCII character set, namely:{0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f,g,h,i,j,k,n,p,q,r,s,t,u,v,x,y,z}. Asnoted, four of the traditional characters from the alphabet wereexcluded: 1) ‘w’ because its pronunciation has multiple syllables andthus takes longer to say; 2) ‘o’ because it is often confused with zero;3) ‘m’ because it is confused with ‘n’; and 4) ‘1’ because it is oftenconfused with one. This encoding results in a readily readable stringfor customer support purposes, for example.

The encoded string is stored into a tag whose name is passed asparameters to the hash transaction object. In one embodiment, this tagis referred to as “sys.hash.sha-1” and a request to recompute the hashcode is queued whenever a file is modified.

Index transaction object 552 pulls an object from its queue andconstructs a request for an external indexing program 555 to index thecorresponding file. In one embodiment, this external indexing program isa third-party software package referred to as Lucene. Other indexingprograms are available and could be used as would be apparent. Theexternal indexing program receives the contents of the file and somemetadata such as the date the file was modified, for example. In oneembodiment of the invention, indexing is performed for only two types offiles: text files and HTML files. These files are comprised of a streamof words readily processed by the external indexing program. In otherembodiments of the invention, a prefilter first converts binary files(such as, for example, PDF files, Word files, etc.) into a stream ofwords and then passes the stream onto the external indexing program. Inother embodiments of the invention, the external indexing programprocesses binary files directly as would be apparent.

The external indexing program uses a front-end filter 557, referred tosometimes as a Grok analyzer 557, that performs various pre-processingsteps on the stream of words generated from the file being indexed.These steps may include tokenizing the stream (determining where thebreaks between words are), removing “'s” (apostrophe-s) from the end ofwords, removing periods from acronyms, converting words to lower case,removing common “stop” words (such as “a,” “the,” “and,” “or,” etc.) andperforming standard Porter stem filtering (removing common suffixes suchas “-ing,” “ed,” etc., and mapping double suffixes to single ones “-ize”plus “-ation” maps to “-ize”) etc.

In one embodiment, the resulting text index files from the externalindexing program are stored out in a file system 558 (or files system508 as would be apparent). Accordingly, in this embodiment, these textindex files are not transactionally secure. In other embodiments, theresulting text index files are stored in object store 520 as would beapparent.

File management system 500 also includes a socket manager 580 that isresponsible for managing incoming connections used as pathways toexecute other remote commands including XML commands and RMI commands.This mechanism provides a parallel or alternate command path to filemanagement system 500 similar to that described as system operationsthrough file system interface 502. Socket manager 580 is to handle XMLcommands. When a client attempts to connect to the server on a specificport, socket manager 580 receives that connection. Socket manager 580manages the number of connections, creates socket reader object 571 andsocket writer object 572, and delegates subsequent read and writeoperations to the corresponding object. In one embodiment, these socketsare full duplex, thereby enabling parallel reading and writing as wouldbe apparent.

Socket reader object 571 reads the socket, packages each XML commandpacket, attaches it to an object, and places that object onto a queue.Socket writer object 572, on the other hand, reads a queue, serializesthose objects from the queue, and outputs them to the output socket.

Socket worker object 565, which run in their own separate thread pools,pull requests off of the corresponding input queue, parses thecorresponding XML command, determine a necessary action and in someinstances, actually executes many of the tasks associated with theseparticular commands. More complex commands may be dispatched toappropriate objects that know how to perform those functions.

For example, in one embodiment of the invention, commands to manipulatetags (i.e., getting tags, setting tags, removing tags, etc.) may enterfile management system 500 as XML commands via socket worker 565. Afterparsing the XML command, socket worker performs path name lookups, etc.,that may be required to obtain either a slot or an entry object and orto set/remove tags, set/read/remove attributes, etc.

Socket worker 565 is also responsible for constructing an appropriateresponse to the client for the requested operation. For example, if theincoming request asked for all of the tags associated with a particularfile, socket worker 565 would first access volume manager 515 and parsethe path name associated with the particular file into a slot object.Then, using the slot object, socket worker 565 accesses thecorresponding entry object. The entry object includes methods that, forexample, determine which tags are associated with that entry object.Using that data, socket worker 565 constructs an XML DOM object, whichrepresents the response. Once constructed, socket worker 565 queues theDOM object up to the corresponding socket writer 572 associated with theclient that issued the original request.

In one embodiment, the requests are tagged with ID numbers therebyallowing file management system 500 to operate completelyasynchronously. This allows a client to submit many requests, one rightafter the other, without waiting for the responses to come back. Thoserequests are then queued and subsequently processed by a pool of socketworkers. As the requests are completed (and not necessarily in the orderin which they were received) and responses are constructed and placed onthe output queue, socket writer 572 sends them out with the same IDmarker associated with the original request. The client can thencorrelate the responses with the requests.

File management system 500 also includes a notification object 560. Atvarious points within the operation of file management system 500, suchas when a new file or folder is added or when tags change in certainways, certain events can be generated. According to one aspect of theinvention, these events may generate XML messages that are sent to aclient, in some instances, completely asynchronously. In order for theclient to indicate its readiness to receive these events, the clientsends a specific command referred to as a watch list command. The clientcollects the names of folders referred to by open windows on the clientand forwards that as a watch list to the server. In this way, the servernow knows which folders every user has open on every connection on everydesktop. Whenever a new file is created, file management system 500searches the watch lists of open folders to determine if any clientscurrently have a folder open that includes the newly created file. Ifso, then a corresponding event is sent asynchronously to all of thoseclients. According to various aspects of the invention, this mechanismworks similarly for regular folders, search folders, and/or queryfolders. A similar mechanism also works for tags where if a tag ischanged on a file that is currently open on a user's desktop, then thatuser will receive an asynchronous event saying that that tag has beenupdated.

Events may be scheduled to occur when, for example, a tag or file isdeleted from any one of these open folders, a file is renamed, etc.Various objects in file management system 500 track which socket writer572 or socket reader 571 corresponds to which user. In other words,within file management system 500 there exists a so-called “back path”from the watch list of open folders to the user. This back path enhancesthe lookup process, making it extremely fast. In one embodiment, thenames of the folders are stored in hash tables with the output being aset of socket readers or socket writers that correspond to thatparticular user. Once this set is determined, an XML notificationmessage may be constructed and queued for the corresponding socketwriter.

File management system 500 also includes an RMI interface 582 thatoperates in a manner similar to socket manager 580, the difference beingno XML in the RMI procedure call. In one embodiment, socket manager 580and RMI interface 582 share common code (i.e., code exclusive of XMLparsing etc.) referred to herein as core calls 584. Core calls 582correspond to the common operations between the RMI interface and theXML interface.

Other functions that may be included in various embodiments of filemanagement system 500 may include logging, unit testing, miscellaneousutilities, etc. These functions are generally well known and may eitherbe incorporated into the system or integrated therewith as third partytools.

Another function that may be included in file management system 500 isan ID number manager (not illustrated). All file system node objects530, including slots 532, entry objects 534, streams 538 and containers537, have associated therewith an ID number. This ID number is unique ona per-volume basis. In some embodiments of the invention, the ID numberis used to name the underlying blob on file system 508 that correspondsto this node object. As described above, each stream object 538 refersto a blob on files system 508 that corresponds to that stream, and thename of that blob is the ID number of that object.

In some embodiments of the invention, ID numbers may be used to look upobjects by their number, for example, with the free-text search index.When a file is indexed in the free-text search sense, its file name isnot stored in the index. Otherwise, any time the file is renamed, itwould have to be re-indexed. Instead, the ID number is used as the nameof the index. When a lookup is performed during a free-text search, thereturned hits include the ID numbers corresponding to the objects thatwere found. This ID number is used to determine which stream objects andaccordingly, which entry objects and which slot objects are implicated.From the slot objects, the name of the object can be determined. UsingID numbers in the index also facilitates a single index file regardlessof whether the corresponding file is linked, live copied, a deferredcopy, etc., as only one instance of that file resides on the disk andthus having multiple index files is unwarranted.

ID number manager assigns the ID numbers. According to one aspect of theinvention, ID numbers are anchored in volume object 525. Because of themanner in which object store 520 operates, if each session were toaccess the volume object for a new ID number as the objects werecreated, a significant number of write/write collisions against thevolume object would result. Instead, ID number manager operates using asingle thread to assign the ID numbers.

At start up, ID number manager requests a block of ID numbers from thevolume object and places them one at a time onto a synchronized queue.While this queue is not persistent, the volume number update process is.More particularly, when the ID number manager asks for a block of IDnumbers, that request is done in a persistent fashion: the updatedvolume object is written back to the object store so that the block thatwas requested is “remembered” if the file management system 500 were tocrash. However, the queue in which these objects are placed is notpersistent. Instead, the ID number manager writes only so many of the IDnumbers, one at a time, to the synchronized queue. Thus, this queue hasa limited depth. Furthermore, the ID number manager only has a limitednumber of these objects that it originally fetched from the volumeobject.

In some embodiments, the ID number manager writes a few of these IDnumbers into this queue and suspends until another thread removes anumber from the queue. Threads requesting an ID number in order tocreate file system objects remove a number from the queue. In order toovercome problems associated with this queue being non-persistent, whenthe ID number manager has placed all of the ID numbers that it fetchedfrom the volume manager on the queue, the ID number manager requestsanother block of ID numbers through an object store transaction. In thisway, the volume object need only periodically re-persist to disk (i.e.,update object store) based on the number of ID numbers fetched at anygiven time from the volume object.

The tag volume is now described in further detail. As implemented in oneembodiment of the invention, tag volume is implemented as a tag folderhierarchy. As described above, tags in file management system 500 arereflected into file system as folder names. This is done be replacingthe dots in a tag name with slashes, and then appending the resultingstring to the root path of the tag volume. For example, with a tagvolume root path of “/volume root/tags/” then a tag referred to as“sys.types” would be reflected in the file system as a folder named“/volume root/tags/sys/types.” Furthermore, the folders corresponding toeach tag are created at the time that the tags are first created.

As also described above, each tag can have one or more metatags appliedto it. One purpose of the metatags is to affect the behavior of the tagsto which they are applied. These metatags are now described in furtherdetail.

Each tag may include a type that is enforced at the time that the tag isset. One type of tag is a user type. A tag of user type has a value ofthe form of domain name/user name. Another type of tag is a date type. Atag of date type has an ISO standard date form. Another type of tag isan icon type. A tag of icon type must include a value that representsthe name of an icon file found in the /volume root/tags folder. Anothertype of tag is a hash type. A tag of hash type has a form of a35-character long string (for encoded representation of SHA-1 hashcode). Another type of tag is a trigger type. A trigger is the name of aJava class that will be verified to ensure sure that it exists, and thatit is derived from the right subclass type to be a valid trigger.Another type of tag is a boolean type. A tag of boolean type can only beset to true or false. Other values are not allowed. Another type of tagis an email type. A tag of email type must include a properly formattede-mail address including a user name and host name. Another type of tagis a password type. A tag of password type has the form of any string,but with the property of returning a string of asterisks (for example)rather than its exact value when the tag is read. Other tags types mayexist as would be apparent.

Another metatag that is enforced on the volume manager is one thatallows new values to be set. This metatag will not allow new values tobe created for that tag. Another metatag records all current and pastvalues for a particular tag. Whenever a new tag value is set toparticular tag name, this metatag, referred to as “tag.values” isupdated so that it includes a current list of all the values that haveever been applied to that particular tag. This allows users todetermine, by browsing the tag volume, which of the values of the tagsare actually being used. Tags may also include a default value so thatwhen the tag is set the default is used if no other value is provided.An owner of the tag may also be specified. This may be used to limit whocan add, modify, delete, view, etc., certain tags.

Tags may be assigned to a tag group, for example, by setting the“tag.group” metatag. Tags that have the same value for the “tag.group”metatag are considered to belong to the same tag group. When a singletag that belongs to a particular tag group is applied to a file, all ofthe other tags in that same tag group are also applied to that file.Similarly, when a tag belonging to a particular tag group is deletedfrom a file, all of the other tags in that tag group are also deleted.Tags in tag groups are intended to be applied and removed together. Insome embodiments, if one tag in a tag group is changed and if any tag inthe tag group has a trigger associated with it, the trigger will fire(whereas normally only the trigger associated with the tag that ischanged would be fired).

In some embodiments of the invention, a metatag of type trigger may beassigned to a tag in the tag folder hierarchy. As described above, thiscorresponds to a Java class that gets invoked at various points in theoperation of file management system 500. For example, triggers may beattached to file operation including opening, closing, reading, and/orwriting of a file. Triggers may also be attached to metadata operationsincluding changing a tag or changing an attribute. In addition, periodictriggers may be invoked as would be apparent, without touching thesystem in any other way. Triggers may perform any number of operationsincluding sending an e-mail, setting various tags, performing fileoperations, writing out to a log file, creating a new file based on someevent, adjusting and/or modifying file attributes, freezing a file,etc., or any other operation that could be programmed using for example,Java code.

An example of a trigger is now described. One type of triggercontemplated by the invention is referred to as an approval trigger. Theapproval trigger is set up to fire whenever any approval-related tagchanges. The approval trigger sets several approval status tags toindicate who has approved a file and who has not, including the variousicon designations. And these tags are then later interpreted by the userinterface. This is all done based on a list of required approvers thatis also attached to the file. The approval trigger may also send ane-mail if so designated by a tag attached to the file or metatag thatattached to one of the tags. The approval tag may also freeze the fileif all of the approvers have approved the file if that is designated.

File management system 500 manages a set of approval-based triggers. Insome embodiments, this set of triggers is managed on a user-by-userbasis, so these tags may all include the security authentication domainand user name of the user who approved the file. For example, one tagassociated with the approval might correspond to a date tag with thename “sys.signature.domain.user.date.” According to the invention, thesetags are applied through a signature XML or RMI call rather thandirectly by the user. This ensures that a formal approval process isfollowed, that certain requirements have been met, that the users havebeen authenticated, etc.

One embodiment of the invention implements four approval-based tags.These include a date tag, a hash code tag associated with the file, astatus of the approval (for example, “signed” or “rejected”), and theapprover's comments relating to their approval or rejection.

In addition to the approval-based tags, this embodiment may also includea set of tags used to control whether other tags (such as theapproval-based tags) are required on all the files that go into afolder. By setting these tags on a folder, then every time a file iscreated or moved in that folder, file management system 500 will requirethat the other tags are set; if not, the create or move operation willnot be allowed.

Another mechanism exists in file management system 500 similar to thetag volume described above. This mechanism is referred to as a uservolume or a user folder hierarchy. As with the tag volume, all users offile management system 500 are reflected into the file system as adirectory of their corresponding user IDs. For a user “rick” in domain“grokker,” there would be a folder in file system 530 named “/volumeroot/users/grokker/rick.” As described above, any number of tags can beattached to that folder to in effect describe that user. For example,these tags could include a human-friendly user name including a firstname and a last name, an e-mail address, a password, a preferredlanguage, as well as authentication tokens and pointers toauthentication servers, etc. This folder may be linked to other foldersthereby designating groups or roles for permission and access purposes.

File management system 500 as thus described provides a framework forimplementing various aspects of the invention that will now bedescribed. The first of these aspects is “live copy” and “smart links.”As described above, any file in file system 530 has associated with it aslot 532, an entry 534, and a stream 538. When a live copy or smart linkcommand is issued with respect to this file, the file system creates asecond slot 532 that points to the existing entry 534, and thus the samestream 538. As has been described above, slots 532 include nameinformation and entries 534 manage tags, and further, multiple slots 532can point to a single entry 534. Thus, after the second slot is created,the file system, in effect, manages two names for the same underlyingobject. The live copy command also attaches a trigger to the secondslot. This trigger is fired when the file is opened or closed, andmanages the synchronization with remote systems.

A similar mechanism may also be used for smart caching and smart backup.A cache or backup trigger is attached to a file so that when the file isopened or closed, the trigger can access a remote cache, synchronize alocal copy, or in the case of a backup, send the modified file off to abackup store.

Deferred copies are implemented using a slot and entry pair. The filesystem permits more than one slot-entry pair to point to the sameunderlying item 536. As described above, the slot manages the name (sothe underlying item can have multiple names) and the entry manages thetags (implying that the underlying item can have different sets oftags). The deferred copy command creates a second slot-entry pairpointing to the same underlying item. The deferred copy providesextremely fast server side copies of an item because the underlying item(including its associated blob, in the case of a stream) is not copied.When the underlying item is opened for writing or modification, thevolume manager detects the multiple entries pointing to the same itemand only then is a copy of the underlying item made. At that time, thesecond slot-entry pair is adjusted to point at the copy as would beapparent.

Identical files are detected using the hash code described above.Whenever a file is modified and closed, a background thread calculates anew hash code for that file. The new hash code is stored in a tagassociated with that file. This causes, through a trigger mechanism,file management system 500 to compare the new hash code with the hashcodes of other files in the system to identify identical files in thefile system. According to one embodiment, the file system objects,namely the slot-entry pairs are rearranged to resemble a deferred copy,and the duplicate blob is removed from disk. Identical files are thuscombined thereby freeing disk space.

Frozen files are implemented by attaching a frozen attribute as aboolean field to an entry object associated with the file. Whenever thisfile is opened, this field is examined to determine the allowedoperations. Nothing happens if the file is opened for reading. However,if the file is opened for writing or creating an error will be thrownand that operation will be prevented. In some embodiments, this fieldmay also be examined when tags are set so that tags on a frozen filecannot be modified, added, deleted, etc. In one embodiment of theinvention, a frozen file is akin to a permanent read only file,including its tags. In various embodiments of the invention, the onlyoperations allowed on a frozen file are reading and renaming.

Query folders are implemented through query tags attached to the folder.Query tags differ from other tags described above in that they can onlybe attached to empty folders. When these tags are set, special links aremade to all of the files that match the query. These links are updatedwhen either the query tags change or when one of the files matching thequery changes.

Search folders are implemented in a similar fashion; however, instead ofperforming a search using the tag mechanism described above, the searchfolder utilizes a free-text search engine. As described above, thesearch engine returns the file ID based on a provided search string andthe file ID is used to get the file name.

File versions are created automatically, either when a user does a filecreate on top of an existing file, or when file management system 500detects a renaming sequence. For example, Microsoft Word uses a renamingsequence that renames the original file to a backup file and thenrenames a temporary file to the name of the original file. The filesystem implements and manages versions by maintaining a linked list ofentries with various state bits that control whether or not thoseentries are shown in directories when the directories are enumerated.When the directory is enumerated, the file system uses these state bitsto determine which versions to display based on, for example, userpreferences. In one embodiment, older versions of files have an ISOstandard date encoded into their names for use and discrimination byother systems, along with the word “version”. This encoding also avoidsname collisions as would happen, for example, if all the versions hadthe same name as the original file. In some embodiments,automatically-created versions can also be renamed with a name chosen bythe user.

Copy pedigrees are also implemented by file management system 500. Whencopies are created using, for example, a server side copy command, theserver tracks these copy operations by having each entry object forwardpoint to a collection of other entries that are copies thereof.Likewise, each entry object may also backward point to the entry fromwhich it was copied. File management system 500 responds to appropriateXML and RMI commands to present these copies pedigrees in a userinterface in an appropriate form to illustrate the migration of copiesfrom place to place.

Undeleting files is implemented as set forth below. As files aredeleted, their corresponding slot objects are renamed and a field in theslot object is set to indicate that the slot has been deleted. When adirectory is enumerated, deleted slots are not shown. This process isreversed when a file is undeleted. The field in the slot is unset andthe name is changed back to its original value. In an analogous way toversions, deleted filenames are marked with the string “deleted” and thedate that the file was deleted. When these files are undeleted, theirnames are marked with the string “undeleted” and the date that they wereundeleted. File management system 500 responds to an appropriate XML orRMI command to toggle a per-user boolean value, managed in container537, which in turn controls whether the deleted files are shown when thecorresponding user enumerates the container. With this field enabled,users can see deleted files in the same context where they wereoriginally located.

Type folders are implemented with a special tag on the folder that filemanagement system 500 examines prior to allowing a file to be addedthere. If the file does not match the specified type, the system willnot allow the file to be placed in that folder.

1. A computerized file management system for use with an existing filesystem, that includes a volume, and for managing electronic files on thevolume, the file management system comprising: a volume managerconfigured to manage the electronic files and to manage metadatarelating to the electronic files, the volume manager being configured toassociate information related to changes made by a user to a selectedfile of the electronic files with the selected file; and a userinterface that enables the user to view and manage, within the filemanagement system, metadata associated with the electronic files, theuser interface configured to: i) graphically display information aboutthe electronic files and the metadata, the information being indicativeof a transaction history of the selected file; and ii) enable the userto manipulate the files and the metadata. 2-28. (canceled)